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The Datagram Congestion Control Protocol (DCCP) Service Codes 
Abstract 


This document describes the usage of Service Codes by the Datagram 
Congestion Control Protocol, RFC 4340. It motivates the setting of a 


Service Code by applications. Service Codes provide a method to 
identify the intended service/application to process a DCCP 
connection request. This provides improved flexibility in the use 


and assignment of port numbers for connection multiplexing. The use 
of a DCCP Service Code can also enable more explicit coordination of 
services with middleboxes (e.g., network address translators and 
firewalls). This document updates the specification provided in RFC 
4340. 


Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 
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document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the BSD License. 


This document may contain material from IETF Documents or IETF 
Contributions published or made publicly available before November 
10, 2008. The person(s) controlling the copyright in some of this 
material may not have granted the IETF Trust the right to allow 
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modifications of such material outside the IETF Standards Process. 


Without obtaining an adequate license from the person(s) 


controlling 


the copyright in such materials, this document may not be modified 
outside the IETF Standards Process, and derivative works of it may 
not be created outside the IETF Standards Process, except to format 
it for publication as an RFC or to translate it into languages other 


than English. 
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Les 


at 


Introduction 


DCCP specifies a Service Code as a 4-byte value (32 bits) that 
describes the application-level service to which a client application 
wishes to connect ([RFC4340], Section 8.1.2). A Service Code 
identifies the protocol (or the standard profile, e.g., [RTP-DCCP]) 
to be used at the application layer. It is not intended to be used 
to specify a variant of an application or a specific variant of a 
protocol (Section 2.2). 


The Service Code mechanism allows an application to declare the set 
of services that are associated with server port numbers. This can 
affect how an application interacts with DCCP. It also allows 
decoupling of the role of port numbers to indicate a desired service 
from the role of port numbers in demultiplexing and state management. 
A DCCP application identifies the requested service by the Service 
Code value in a DCCP-Request packet. Each application therefore 
associates one or more Service Codes with each listening port 
([REC4340], Section 8.1.2). 


The use of Service Codes can assist in identifying the intended 
service by a firewall and may assist other middleboxes (e.g., a proxy 
server or network address translator (NAT) [RFC2663]). Middleboxes 
that desire to identify the type of data a flow claims to transport 
should utilize the Service Code for this purpose. When consistently 
used, the Service Code can provide a more specific indication of the 
actual service (e.g., indicating the type of multimedia flow or 
intended application behaviour) than deriving this information from 
the server port value. 


The more flexible use of server ports can also offer benefits to 
applications where servers need to handle very large numbers of 
simultaneous-open ports to the same service. 


RFC 4340 omits a description of the motivation behind Service Codes, 
and it does not properly describe how Well Known and Registered 
server ports relate to Service Codes. The intent of this document is 
to clarify these issues. 


RFC 4340 states that Service Codes are not intended to be DCCP- 
specific. Service Codes, or similar concepts, may therefore also be 
useful to other IETF transport protocols. 


1. History 


It is simplest to understand the motivation for defining Service 
Codes by describing the history of the DCCP protocol. 
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Most current Internet transport protocols (TCP [RFC793], UDP 
[RFC768], SCTP (the Stream Control Transmission Protocol) [RFC4960], 
and UDP-Lite [RFC3828]) use "Published" port numbers from the Well 


Known or Registered number spaces [RFC814]. These 16-bit values 
indicate the application service associated with a connection or 
message. The server port must be known to the client to allow a 


connection to be established. This may be achieved using out-of-band 
Signalling (e.g., described using SDP [RFC4566]), but more commonly a 
Published port is allocated to a particular protocol or application; 
for example, HTTP commonly uses port 80 and SMTP commonly uses port 
25. Making a port number Published [RFC1122] involves registration 
with the Internet Assigned Numbers Authority (IANA), which includes 
defining a service by a unique keyword and reserving a port number 
from among a fixed pool [IANA]. 


In the earliest draft of DCCP, the authors wanted to address the 
issue of Published ports in a future-proof manner, since this method 
suffers from several problems: 


o The port space is not sufficiently large for ports to be easily 
allocated (e.g., in an unregulated manner). Thus, many 
applications operate using unregistered ports, possibly colliding 
with use by other applications. 


o The use of port-based firewalls encourages application writers to 
disguise one application as another in an attempt to bypass 
firewall filter rules. This motivates firewall writers to use 
deep packet inspection in an attempt to identify the service 
associated with a port number. 


o ISPs often deploy transparent proxies, primarily to improve 
performance and reduce costs. For example, TCP requests destined 
to TCP port 80 are often redirected to a web proxy. 


These issues are coupled. When applications collide on the same 
Published-but-unregistered port, there is no simple way for network 
security equipment to tell them apart, and thus it is likely that 
problems will be introduced through the interaction of features. 


There is little that a transport protocol designer can do about 
applications that attempt to masquerade as other applications. For 
ones that are not attempting to hide, the problem may be simply that 
they cannot trivially obtain a Published port. Ideally, it should be 
sufficiently easy that every application writer can request a Well 
Known or Registered port and receive one instantly with no questions 
asked. The 16-bit port space traditionally used is not large enough 
to support such a trivial allocation of ports. 
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Thus, the designers of DCCP sought an alternative solution. The idea 
was simple. A 32-bit server port space should be sufficiently large 
to enable use of very simple allocation policies. However, overhead 
considerations made a 32-bit port value undesirable (DCCP needed to 
be useful for low-rate applications). 


The solution in DCCP to this problem was to use a 32-bit Service Code 
[RFC4340] that is included only in the DCCP-Request packet. The use 
of a 32-bit value was intended to make it trivially simple to obtain 
a unique value for each application. Placing the value in a DCCP- 
Request packet requires no additional overhead for the actual data 
flow. It is however sufficient for both the end systems, and 
provides any stateful middleboxes along the path with additional 
information to understand what applications are being used. 


Early discussion of the DCCP protocol considered an alternative to 
the use of traditional ports; instead, it was suggested that a client 
use a 32-bit identifier to uniquely identify each connection and that 


the server listen on a socket bound only to a Service Code. This 
solution was unambiguous; the Service Code was the only identifier 
for a listening socket at the server side. The DCCP client included 


a Service Code in the request, allowing it to reach the corresponding 
listening application. One downside was that this prevented 
deployment of two servers for the same service on a single machine, 
something that is trivial with ports. The design also suffered from 
the downside of being sufficiently different from existing protocols 
that there were concerns that it would hinder the use of DCCP through 
NATs and other middleboxes. 


RFC 4340 abandoned the use of a 32-bit connection identifier in favor 
of two traditional 16-bit port values, one chosen by the server and 
one by the client. This allows middleboxes to utilize similar 
techniques for DCCP, UDP, TCP, etc. However, it introduced a new 
problem: "How does the server port relate to the Service Code?" The 
intent was that the Service Code identified the application or 
protocol using DCCP, providing middleboxes with information about the 
intended use of a connection, and that the pair of ports effectively 
formed a 32-bit connection identifier, which was unique between a 
pair of end systems. 


The large number of available, unique Service Code values allows all 
applications to be assigned a unique Service Code. However, there 
remained a problem: the server port was chosen by the server, but the 
client needed to know this port to establish a connection. It was 
undesirable to mandate out-of-band communication to discover the 
server port. The chosen solution was to register DCCP server ports. 
The limited availability of DCCP server ports appears to contradict 
the benefits of DCCP Service Codes because, although it may be 
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trivial to obtain a Service Code, it has not traditionally been 
trivial to obtain a Registered port from IANA and, in the long-run, 
it may not be possible to allocate a unique Registered DCCP port to 
new applications. As port numbers become scarce, this motivates the 
need to associate more than one Service Code with a listening port 
(e.g., two different applications could be assigned the same server 
port and need to run on the same host at the same time, 
differentiated by their different associated Service Codes). 


Service Codes provide flexibility in the way clients identify the 
server application to which they wish to communicate. The mechanism 
allows a server to associate a set of server ports with a service. 
The set may be common with other services available at the same 
server host, allowing a larger number of concurrent connections for a 
particular service than possible when the service is identified by a 
single Published port number. 


1.2. Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


2. An Architecture for Service Codes 


DCCP defines the use of a combination of ports and Service Codes to 
identify the server application ([RFC4340], Section 8.1.2). These 
are described in the following sections. 


ena E IANA Port Numbers 


In DCCP, the packets belonging to a connection are demultiplexed 
based on a combination of four values {source IP address, source 
port, dest IP address, dest port}, as in TCP. An endpoint address is 
associated with a port number (e.g., forming a socket) and a pair of 
associations uniquely identifies each connection. Ports provide the 
fundamental per-packet demultiplexing function. 


The Internet Assigned Numbers Authority currently manages the set of 
globally reserved port numbers [IANA]. The source port associated 
with a connection request, often known as the "ephemeral port", is 
traditionally in the range 49152-65535 and also includes the range 
1024-49151. The value used for the ephemeral port is usually chosen 
by the client operating system. It has been suggested that a 
randomized choice port number value can help defend against "blind" 
attacks [Rand] in TCP. This method may be applicable to other IETF- 
defined transport protocols, including DCCP. 
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Traditionally, the destination (server) port value associated with a 
service is determined either by an operating system index that points 
to a copy of the IANA table (e.g., getportbyname() in Unix, which 
indexes the /etc/services file) or by the application specifying a 
direct mapping. 


The UDP and TCP port number space: 0..65535, is split into three 
ranges [RFC2780]: 


o 0..1023 "Well Known", also called "system" ports, 
o 1024..49151 "Registered", also called "user" ports, and 
o 49152..65535 "Dynamic", also called "private" ports. 


DCCP supports Well Known and Registered ports. These are allocated 
in the DCCP IANA Port Numbers registry ([RFC4340], Section 19.9). 
Each Registered DCCP port MUST be associated with at least one pre- 
defined Service Code. 


Applications that do not need to use a server port in the Well Known 
or Registered range SHOULD use a Dynamic server port (i.e., one not 
required to be registered in the DCCP Port registry). Clients can 
identify the server port value for the services to which they wish to 
connect using a range of methods. One common method is by reception 
of an SDP record (Section 2.6) exchanged out-of-band (e.g., using SIP 
[RFC3261] or the Real Time Streaming Protocol (RTSP) [RFC2326]). DNS 
SRV resource records also provide a way to identify a server port for 
a particular service based on the service’s string name [RFC2782]. 


Applications that do not use out-of-band signalling can still 
communicate, provided that both client and server agree on the port 
value to be used. This eliminates the need for each registered 
Service Code to be allocated to an IANA-assigned server port (see 
also Section 2.7). 


2.2. DCCP Service Code Values 


DCCP specifies a 4-byte Service Code ([RFC4340], Section 8.1.2) 
represented in one of three forms: a decimal number (the canonical 
method), a 4-character ASCII string [ANSI.X3-4.1986], or an 8-digit 
hexadecimal number. All standards assigned Service Codes, including 
all values assigned by IANA, are required to use a value that may be 
represented using a subset of the ASCII character set. Private 
Service Codes do not need to follow this convention, although RFC 
4340 suggests that users choose Service Codes that may also be 
represented in ASCII. 
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The Service Code identifies the application-level service to which a 
client application wishes to connect. For example, services have 
been defined for the Real-Time Protocol (RTP) [RTP-DCCP]. Ina 
different example, Datagram Transport Layer Security (DTLS) [RFC5238] 
provides a transport-service (not an application-layer service); 
therefore, applications using DTLS are individually identified by a 
set of corresponding Service Code values. 


Endpoints MUST associate a Service Code with every DCCP socket 
[RFC4340], both actively and passively opened. The application will 
generally supply this Service Code. A single passive-listening port 
may be associated with more than one Service Code value. The set of 
Service Codes could be associated with one or more server 
applications. This permits a more flexible correspondence between 
services and port numbers than is possible using the corresponding 
socket pair (4-tuple of layer-3 addresses and layer-4 ports). In the 
currently defined set of packet types, the Service Code value is 
present only in DCCP-Request ([RFC4340], Section 5.2) and DCCP- 
Response packets ([RFC4340], Section 5.3). Note that new DCCP packet 
types (e.g., [RFC5596]) could also carry a Service Code value. 


2.2.1. New Versions of Applications or Protocols 


Applications/protocols that provide version negotiation or indication 
in the protocol operating over DCCP do not require a new server port 
or new Service Code for each new protocol version. New versions of 
such applications/protocols SHOULD continue to use the same Service 
Code. If the application developers feel that the new version 
provides significant new capabilities (e.g., that will change the 
behavior of middleboxes), they MAY allocate a new Service Code 
associated with the same or different set of Well Known ports. If 
the new Service Code is associated with a Well Known or Registered 
port, the DCCP Ports registry MUST also be updated to include the new 
Service Code value, but MAY share the same server port assignment (s). 


2.3. Service Code Registry 


The set of registered Service Codes specified for use within the 
general Internet are defined in an IANA-controlled name space. IANA 
manages new allocations of Service Codes in this space [RFC4340]. 
Private Service Codes are not centrally allocated and are denoted by 
the decimal range 1056964608-1073741823 (i.e., 32-bit values with the 
high-order byte equal to a value of 63, corresponding to the ASCII 
character '?'). 


Associations of Service Code with Well Known ports are also defined 
in the IANA DCCP Port registry (Section 2.1). 
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2.4. Zero Service Code 


A Service Code of zero is "permanently reserved (it represents the 
absence of a meaningful Service Code)" [RFC4340]. This indicates 
that no application information was provided. RFC 4340 states that 
applications MAY be associated with this Service Code in the same way 


as other Service Code values. This use is permitted for any server 
port. 


This document clarifies Section 19.8 of RFC 4340 by adding the 
following: 


Applications SHOULD NOT use a Service Code of zero. 


Application writers that need a temporary Service Code value 
SHOULD choose a value from the private range (Section 2.3). 


Applications intended for deployment in the Internet are 
encouraged to use an IANA-defined Service Code. If no specific 


Service Code exists, they SHOULD request a new assignment from the 
IANA. 


2.5. Invalid Service Code 


RFC 4340 defines the Service Code value of 4294967295 in decimal 
(OXFFFFFFFF) as "invalid". This is provided so implementations can 
use a special 4-byte value to indicate "no valid Service Code". 
Implementations MUST NOT accept a DCCP-Request with this value, 


SHOULD NOT allow applications to bind to this Service Code value 
[RFC4340]. 


and 


2.6. SDP for Describing Service Codes 


Methods that currently signal destination port numbers, such as the 
Session Description Protocol (SDP) [RFC4566], require an extension to 
support DCCP Service Codes [RTP-DCCP]. 


2.7. A Method to Hash the Service Code to a Dynamic Port 


Applications that do not use out-of-band signalling or an IANA- 
assigned port still require both the client and server to agree on 
the server port value to be used. This section describes an optional 
method that allows an application to derive a default server port 


number from the Service Code. The returned value is in the Dynamic 
port range [RFC4340]: 
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int s_port; /* server port */ 
s_port = ((sc[0]<<7)%*(sc[1]<<5) *(sc[2]<<3)%*sc[3]) | O0xCO000; 
if (s_port==0xFFFF) {s_port = 0x C000; } 


where sc[] represents the 4 bytes of the Service Code, and sc[3] is 
the least significant byte. For example, this function associates 
SC:fdpz with the server port 64634. 


This algorithm has the following properties: 


o It identifies a default server port for each service. 


o It seeks to assign different Service Codes to different ports, but 
does not guarantee an assignment is unique. 


o It preserves the 4 lowest bits of the final bytes of the Service 
Code, which allows many common series of Service Codes to be 
mapped to a set of adjacent port numbers, e.g., Fool, and Foo2; 
Fooa and Foob would be assigned adjacent ports. (Note: this 
consecutive numbering only applies to characters in the range 0-9 
and A-O and P-Z. When the characters cross a range boundary, the 
algorithm introduces a discontinuity, resulting in mapping to 
non-consecutive ports. Hence, Fooo and Foop respectively map to 
the decimal values of 65015 and 65000). 


o It avoids the port OxFFFF, which is not accessible on all host 
platforms. 


Applications and higher-layer protocols that have been assigned a 
Service Code (or use a Service Code from the unassigned private 
space) may use this method. It does not preclude other applications 
using the selected server port, since DCCP servers are differentiated 
by the Service Code value. 

3. Use of the DCCP Service Code 
The basic operation of Service Codes is as follows: 
A client initiating a connection: 

- issues a DCCP-Request with a Service Code and chooses a 


destination (server) port number that is expected to be 
associated with the specified Service Code at the destination. 
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A server that receives a DCCP-Request: 


- determines whether an available service matching the Service 
Code is supported for the specified destination server port. 
The session is associated with the Service Code and a 
corresponding server. A DCCP-Response is returned. 


- if the service is not available, the session is rejected and a 
DCCP-Reset packet is returned. 


3.1. Setting Service Codes at the Client 


A client application MUST associate every DCCP connection (and hence 
every DCCP active socket) with a single Service Code value 


[RFC4340]). This value is used in the corresponding DCCP-Request 
packet. 
3.2. Using Service Codes in the Network 


DCCP connections identified by the Service Code continue to use IP 
addresses and ports, although neither port number may be Published. 


Port numbers and IP addresses are the traditional methods to identify 
a flow within an IP network. Middlebox [RFC3234] implementors 
therefore need to note that new DCCP connections are identified by 
the pair of server port and Service Code in addition to the IP 
address. This means that the IANA may allocate a server port to more 
than one DCCP application [RFC4340]. 


Network address and port translators, known collectively as NATs 
[RFC2663], may interpret DCCP ports ([RFC2993] and [RFC5597]). They 
may also interpret DCCP Service Codes. Interpreting DCCP Service 
Codes can reduce the need to correctly interpret port numbers, 
leading to new opportunities for network address and port 
translators. Although it is encouraged to associate specific 
delivery properties with the Service Code, e.g., to identify the 
real-time nature of a flow that claims to be using RIP, there is no 
guarantee that the actual connection data corresponds to the 
associated Service Code. A middlebox implementor may still use deep 
packet inspection, and other means, in an attempt to verify the 
content of a connection. 


The use of the DCCP Service Code can potentially lead to interactions 
with other protocols that interpret or modify DCCP port numbers 
[RFC3234]. The following additional clarifications update the 
description provided in Section 16 of RFC 4340: 
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o A middlebox that intends to differentiate applications SHOULD 
test the Service Code in addition to the destination or source 
port of a DCCP-Request or DCCP-Response packet. 


o A middlebox that does not modify the intended application 
(e.g., NATs [RFC5597] and Firewalls) MUST NOT change the 
Service Code. 


o A middlebox MAY send a DCCP-Reset in response to a packet with 
a Service Code that is considered unsuitable. 


3.3. Using Service Codes at the Server 


The combination of the Service Code and server port disambiguates 
incoming DCCP-Requests received by a server. The Service Code is 
used to associate a new DCCP connection with the corresponding 
application service. Four cases can arise when two DCCP server 
applications passively listen on the same host: 


o The simplest case arises when two servers are associated with 
different Service Codes and are bound to different server ports 
(Section 3.3.1). 


o Two servers may be associated with the same DCCP Service Code 
value but be bound to different server ports (Section 3.3.2). 


o Two servers could use different DCCP Service Code values and be 
bound to the same server port (Section 3.3.1). 


o Two servers could attempt to use the same DCCP Service Code and 
bind to the same server port. A DCCP implementation MUST 
disallow this, since there is no way for the DCCP host to 
direct a new connection to the correct server application. 


RFC 4340 (Section 8.1.2) states that an implementation: 


o MUST associate each active socket with exactly one Service Code 
on a specified server port. 


In addition, Section 8.1.2 of REC 4340 also states: 


o Passive sockets MAY, at the implementation’s discretion, be 
associated with more than one Service Code; this might let 
multiple applications, or multiple versions of the same 
application, listen on the same port, differentiated by Service 
Code. 
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This document updates the above text from RFC 4340 by replacing it 
with the following: 


o An implementation SHOULD allow more than one Service Code to be 
associated with a passive server port, enabling multiple 
applications, or multiple versions of an application, to listen 
on the same port, differentiated by the associated Service 
Code. 


It also adds: 


o An implementation SHOULD provide a method that informs a server 
of the Service Code value that was selected by an active 
connection. 


A single passively opened (listening) port MAY therefore be 
associated with multiple Service Codes, although an active (open) 
connection can only be associated with a single Service Code. A 
single application may wish to accept connections for more than one 
Service Code using the same server port. This may allow a server to 
offer more than the limit of 65,536 services depending on the size of 
the Port field. The upper limit is based solely on the number of 
unique connections between two hosts (i.e., 4,294,967,296). 


3.3.1. Reception of a DCCP-Request 


When a DCCP-Request is received and the specified destination port is 
not bound to a server, the host MUST reject the connection by issuing 
a DCCP-Reset with the Reset Code "Connection Refused". A host MAY 
also use the Reset Code "Too Busy" ([RFC4340], Section 8.1.3). 


When the requested destination port is bound to a server, the host 
MUST also verify that the server port is associated with the 
specified Service Code (there could be multiple Service Code values 
associated with the same server port). Two cases can occur: 


o If the receiving host is listening on a server port and the DCCP- 
Request uses a Service Code that is associated with the port, the 
host accepts the connection. Once connected, the server returns a 
copy of the Service Code in the DCCP-Response packet, completing 
the initial handshake [RFC4340]. 


o If the server port is not associated with the requested Service 
Code, the server SHOULD reject the request by sending a DCCP-Reset 
packet with the Reset Code 8, "Bad Service Code" ([RFC4340], 
Section 8.1.2), but MAY use the reason "Connection Refused". 


Fairhurst Standards Track [Page 13] 


RFC 5595 DCCP Service Codes September 2009 


After a connection has been accepted, the protocol control block is 
associated with a pair of ports, a pair of IP addresses, and a single 
Service Code value. 


3.3.2. Multiple Associations of a Service Code with Ports 


DCCP Service Codes are not restricted to specific ports, although 
they may be associated with a specific Well Known port. This allows 
the same DCCP Service Code value to be associated with more than one 
server port (in either the active or passive state). 


3.3.3. Automatically Launching a Server 


A host implementation may permit a service to be associated with a 
server port (or range of ports) that is not permanently running at 
the server. In this case, the arrival of a DCCP-Request may require 
a method to associate a DCCP-Request with a server that handles the 
corresponding Service Code. This operation could resemble that of 
"inetd" [inetd]. 


As in the previous section, when the specified Service Code is not 
associated with the specified server port, the connection MUST be 
aborted and a DCCP Reset message sent [RFC4340]. 


4. Security Considerations 


The security considerations of RFC 4340 identify and offer guidance 
on security issues relating to DCCP. This document discusses the 
usage of Service Codes. It does not describe new protocol functions. 


All IPsec modes protect the integrity of the DCCP header. This 
protects the Service Code field from undetected modification within 
the network. In addition, the IPsec Encapsulated Security Payload 
(ESP) mode may be used to encrypt the Service Code field, hiding the 
Service Code value within the network and also preventing 
interpretation by middleboxes. The DCCP header is not protected by 
application-layer security (e.g., the use of DTLS [RFC5238] as 
specified in DTLS/DCCP [RFC4347]). 


There are four areas of security that are important: 
1. Server Port number reuse (Section 4.1). 
2. Interaction with NATs and firewalls (Section 3.2 describes 


middlebox behavior). Requirements relating to DCCP are described 
in [RFC5597]. 
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3. Interpretation of DCCP Service Codes overriding traditional use of 
reserved/Well Known port numbers (Section 4.2). 


4. Interaction with IPsec and DTLS security (Section 4.3). 
4.1. Server Port Number Reuse 


Service Codes are used in addition to ports when demultiplexing 
incoming connections. This changes the service model to be used by 
applications and middleboxes. The Port Numbers registry already 
contains instances of multiple application registrations for a single 
port number for TCP and UDP. These are relatively rare. Since the 
DCCP Service Code allows multiple applications to safely share the 
same port number, even on the same host, server port number reuse in 
DCCP may be more common than in TCP and UDP. 


4.2. Association of Applications with Service Codes 


The use of Service Codes provides more ready feedback that a concrete 
service is associated with a given port on a server than for a 
service that does not employ Service Codes. By responding to an 
inbound connection request, systems not using these codes may 
indicate that some service is, or is not, available on a given port, 
but systems using this mechanism immediately provide confirmation (or 
denial) that a particular service is present. This may have 
implications in terms of port scanning and reconnaissance. 


Care needs to be exercised when interpreting the mapping of a Service 
Code value to the corresponding service. The same service 
(application) may be accessed using more than one Service Code. 
Examples include the use of separate Service Codes for an application 
layered directly upon DCCP and one using DTLS transport over DCCP 
[RFC5238]. Other possibilities include the use of a private Service 
Code to map to an application that has already been assigned an IANA- 
defined Service Code value, or multiple Service Code values that map 
to a single application providing more than one service. Different 
versions of a service (application) may also be mapped to a 
corresponding set of Service Code values. 


Processing of Service Codes may imply more processing than currently 
associated with incoming port numbers. Implementors need to guard 
against increasing opportunities for Denial of Service attacks. 


4.3. Interactions with IPsec 
The Internet Key Exchange protocol (IKEv2) does not currently specify 


a method to use DCCP Service Codes as a part of the information used 
to set up an IPsec security association. 
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IPsec uses port numbers to perform access control in transport mode 
[RFC4301]. Security policies can define port-specific access control 
(PROTECT, BYPASS, DISCARD) as well as port-specific algorithms and 
keys. Similarly, firewall policies allow or block traffic based on 
port numbers. 


Use of port numbers in IPsec selectors and firewalls may assume that 
the numbers correspond to Well Known services. It is useful to note 
that there is no such requirement; any service may run on any port, 
subject to mutual agreement between the endpoint hosts. Use of the 
Service Code may interfere with this assumption both within IPsec and 
within other firewall systems, but it does not add a new 
vulnerability. New implementations of IPsec and firewall systems may 
interpret the Service Code when implementing policy rules, but should 
not rely on either port numbers or Service Codes to indicate a 
specific service. 


5. IANA Considerations 


This document does not update the IANA allocation procedures for the 
DCCP Port Number and DCCP Service Codes Registries as defined in RFC 
4340. 


For completeness, the document notes that it is not required to 
supply an approved document (e.g., a published RFC) to support an 
application for a DCCP Service Code or port number value, although 
RFCs may be used to request Service Code values via the IANA 
Considerations section. A specification is however required to 
allocate a Service Code that uses a combination of ASCII digits, 
uppercase letters, and character space, ’-’, ’.’, and '/') [RFC4340]. 
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